grpc/server: fork client call options - #2813
Conversation
arjan-bal
changed the title
dfawley
left a comment
dfawley
left a comment
There was a problem hiding this comment.
Sorry, I missed this one yesterday.. On the client, call options allow the application to configure the call. On the server, though, this doesn't really make sense, and the current struct is empty. Should this concept just be removed entirely instead? I think we were going to pass all the out-of-band stuff related to the call (e.g. the deadline) via a task-local context?
|
So, we can probably try to keep it explicit in the generic API(like we do with RequestHeaders right now) to keep things simple. Our codegen will be responsible for creating the tasklocal when calling the application handler . We could alternatively remove both CallOptions and RequestHeaders in favour of a tasklocal context from the generic API itself. |
|
That's a good point; we can probably make everything explicit, and that should be fine. But then what else is going into the client side or the server side that makes them distinct? The only existing field is deadline which does apply to both. So why are we splitting this now? |
3 participants
Currently, the
server::Handle::handle()method acceptsclient::CallOptions. However, server-side options are distinct from client-side options and should not share the same struct. This PR introduces a dedicatedserver::CallOptionsstruct for the server APIs.